The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely complicated devices. To be sure, today's computers are more sophisticated than early systems such as the EDVAC. Fundamentally speaking, though, the most basic requirements levied upon computer systems have not changed. Now, as in the past, a computer system's job is to access, manipulate, and store information. This fact is true regardless of the type or vintage of computer system.
One of the techniques computer designers use to improve the way in which a computer system deals with information is to interconnect a variety of individual computers (“nodes”) into a distributed computer environment (“network”). In this way, each individual node can benefit from the resources available to all of the other nodes. Some well-known examples of a network are the Internet and intranets. In many networks, some of the nodes act as providers of services or functionality, and other nodes act as consumers of services or functionality. The providers of information or functionality are commonly known as “servers.” The consumers of the information or functionality are commonly called “clients.”
Conventional networks assumed that the server and its clients operated in the same locale and time zone. With the rise of global networks, however, this assumption no longer holds true. Managed nodes in a system are often located across national boundaries. Unfortunately, this assumption creates a number of difficulties because users in different locales and time zones generally use different languages, currencies, and information formatting conventions. Consequently, a remote user will frequently make a request whose results must be computed in accordance to cultural expectations that differ from those of the server's locale or time zone. Thus, for example, when a conventional server processes a request from a remote user, the server will execute the request under the locale or time zone of the server and, as a result, will impose its own local formatting conventions. This causes the remote user to receive the results of the request in a format that is undesired by that user.
One area posing special problems with regard to handling locale- and time zone-relevant conventions within remote requests is message-oriented middleware (“MOM”.) MOM systems play important roles in the design and integration of enterprise systems because they allow for communications between applications on dissimilar systems without time-consuming custom programming. This “loose coupling” feature, in turn, allows organizations to connect different computer systems in diverse geographical locations using dissimilar information technology infrastructures into a seamless operation.
Conventional MOM systems generally provide facilities to create, populate, send, and receive messages. MOM systems may further provide facilities for asynchronous as well as synchronous message delivery; support broadcasting messages to one or several destinations; and provide qualities of service on a per-message basis, such as guaranteed delivery. Java language programs can utilize MOM systems through the Java Message Service (“JMS”). JMS defines a set of standard communication rules (frequently called an “application program interface” or “API”) that specify how a JMS client will access the facilities of any supporting MOM system. That is, JMS standardizes the usage of MOM facilities, the implementations of which support JMS and may be provided by any entity (called the “JMS provider”), within Java language programs; and like Java, JMS can be used across different types of computer systems.
In a typical scenario, a JMS message sending client (“JMS producer”) transmits computation requests in the form of a JMS message to a consuming client (“JMS consumer”) using a JMS destination, typically referred to as a “queue” in point-to-point messaging (or “topic” in publish/subscribe messaging.) The JMS consumer would synchronously receive the incoming message from the queue. In a managed application server environment, such as the Java 2 Platform Enterprise Edition (“J2EE”), an Enterprise JavaBean (“EJB”) container would commonly receive the incoming message and asynchronously dispatch it, via a JMS queue, to a well-defined method of the appropriate server application component, commonly, a Message-driven Enterprise Java Bean (“MDB”). JMS consumers perform their business computation utilizing the message's content and return any results to the original message producer client via a new JMS message. Additional details about JMS APIs and messages can be found in the JMS 1.1 specification, which is herein incorporated by reference. Additional details about J2EE and MDBs can be found in the J2EE 1.3 and EJB 2.0 specifications, which are also herein incorporated by reference.
Unfortunately, many of the business computations requested by JMS messages are locale and time zone-sensitive in nature. Existing MOM architectures and implementations, including those supporting JMS, follow the conventional client-server assumption that the message producer and consumer are located in the same locale and time zone. As a result, the message consumer process freely imposes its locale and time zone in the locale- and time zone-sensitive operations requested by the message producer process. The locale and time zone mismatch between the JMS client and the corresponding message-consuming MDB can lead to a variety of problems, such as unexpected and potentially incorrect computations.
FIG. 1 illustrates one such mismatch scenario between a Spanish-locale JMS client 110 and an MDB 120 hosted in an American-locale EJB container 125. The JMS client 110 and the MDB 120 communicate via JMS providers 140, 150 and a MOM application 160. The MDB 120 (probably in conjunction with other EJBs 130) computes a formatted date, a formatted currency and a collated list in response to a message from the JMS client 110. The conventional J2EE implementations will typically compute all the results in the American locale. The JMS client 110, however, expects the results of locale-sensitive computations in its Spanish locale, and not in the MDB's 120 American locale. Although those skilled in the art will appreciate that the MDB 120 in this example could have computed the locale-sensitive results in the JMS client's 110 Spanish locale if the MDB could have accessed the JMS client's 110 locale information, the present JMS infrastructure does not contain a mechanism to propagate the message producer's internationalization information in JMS messages. Another drawback with the present JMS and J2EE architectures is that it is silent about the distribution and utilization of internationalization information in JMS messages.
U.S. patent application Ser. No. 09/870,319, filed May 20, 2001; U.S. patent application Ser. No. 10/000,686, filed Oct. 31, 2001; and U.S. patent application Ser. No. 10/041,219, filed Jan. 8, 2002, which are herein incorporated by reference in their entirety, introduced two new service programming interfaces (“SPI”). The first SPI (“SPI1”) extracts an invocation internationalization context associated with the current thread of execution from a thread context manager component. The second SPI (“SPI2”) associates a caller internationalization context with the current thread of execution again in the same thread context manager component. These two SPIs are part of an infrastructure for internationalization in distributed, heterogeneous managed environments. The present application extends this internationalization service infrastructure to the domain of MOMs.
Accordingly, a need exists for a method and system for processing MOM messages that addresses the problem of locale and time zone mismatches between the message producer and the message consumer.